home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Group 42-Sells Out! - The Information Archive
/
Group 42 Sells Out (Group 42) (1996).iso
/
hack
/
nsa
/
nsa1-2.txt
< prev
next >
Wrap
Text File
|
1995-11-30
|
33KB
|
694 lines
--=] National Security Anarchists [=--
--=] Volume I, Issue II [=--
--=] Date Release: 06/23/91 [=--
== NSA Introduction ==
Welcome to the second release of NSA newsletter. We have gotten quite a
response from our first newsletter, hope you get as much as a orgasm off
this one. Now let's get serious...
-------------------------------------------------------------------------------
Table of Contents
Section Contents
--------- --------------------------------------------------
2.0 NSA Introduction
2.1 Table of Contents
2.2 5ESS Switch, Software Release Retrofit Procedures
2.3 Trunk Port Capacity Provisioning for COs
2.4 ATM Research
2.5 Teleos: New Access Server Enhancements
2.6 SunOS /bin/mail Vulnerability/Credit: Sun/Os
2.7 NSA Information
-------------------------------------------------------------------------------
--=] National Security Anarchists [=--
--=] Volume I, Issue II [=--
--=] Presents [=--
== 5ESS Switch ==
== Software Release Retrofit Procedures ==
== 5E4 to 5E5 Software Releases ==
== AT&T 235-105-244 ==
GENERAL
This addendum supplements AT&T 235-105-244, Issue 1.03. It is to be
placed at the beginning of the manual. The information included in
this addendum will be incorporated into the next regular update of the
manual.
This addendum is issued to provide changes which have become apparent
since the last issue of the manual.
CHANGES TO MANUAL
Page 5-88, Step (replace)
3. The following step may be performedin teleprocessing offices to provide
backup AMA data in the vent that data from the final teleprocessing
session is lost or mutilated at the host collector. In performing this
step, the time interval from now to the system initialization is
increased by the amount of time required to generate the AMA tape.
Caution: All AMA data recorded between the final AMA teleprocessing
session and the initialization will be lost. Although the
following step will hlpe ensure the integrity of previously
recorded AMA data, the amount of AMA data that will be lost at
initialization time may increase by the amount of AMA data
recorded during the aforementioned time interval.
a. For offices that use teleprocessing, an optional manual AMA tape
writing session to dump secondary AMA blocks can be performed at this
time (AT&T 235-105-210, Procedure 3.19). This tape should be saved
for backup purposes.
Page 5-89, Step 5a (replace)
a. Single-stream office - enter message:
MSG OP:AMA:DISK;
Response: REPT AMA DISK SUMMARY FOR STREAM STx
DISK IS CURRENTLY xx% FULL
NUMBER OF PRIMARY AMA BLOCKS IN USE
IS APPROXIMATELY: xx
Comment : Due to design constraints, there may be a small amount of
primary AMA data in use on disk at this point.
To read the remaining primary AMA records;, start another
AMA teleprocessing or tape session (repeat Step 2).
To minimize the loss of AMA records, continue to initiate
AMA sessions until the number of primary blocks in use
(given by OP:AMA:DISK) reaches an acceptable level given
call traffic.
Page 5-93, Step 4 (replace)
4. Note 1: If ONTCs are ACTIVE MAJOR/MINOR (that is, duplex) on MCC Page
1209, uses S as the application parameter (to preserve stable
calls). If ONTCs are not duplex, use R sa the application
parameter.
Note 2: At this time, CU 1 contains 3 circuit packs that are not
compatible with the 5E4 software release currently cycling in the
AM. When CU 1 is forced on-line during the following initalizing
sequence, the switch will immediately go into a DMERT Level 3
recovery. It is essential that the AM boot (42-S-54) be
performed immediately after forcing CU 1 on-line.
To perform the initialization, enter the following commands on the EAI Page:
a. To force CU 1 on-line, enter:
CMD 11 Force CU 1 on-line, switch goes into level 3
recovery
Force CU 1? (y/n) y Force CU 1 on-line after "y" is entered
b. To set the apllication parameter, enter the following commands on the EAI
Page:
CMD 42 Sets application parameter mode
PARAMETER: S or R S saves stable calls; R does not
WARNING: Verify thateither S or R apperas (and is backlighted) to the
right of the APPL PARMA field on the EAI Page before proceeding.
If the S or R is not present and backlighted, reenter the 42 and
S/R commands again before proceeding to the boot.
c. To perform the initialization, enter the following commands on the EAI
Page:
CMD 54 Full AM boot on new software release
Boot? (y/n) y Boot begins after "y" is entered
Page 5-94, Section 5.6.7.1 (add after the last sentence)
As the AM recovers, ovserve the ROP for Asserts. If any Assers are
received, analyze them using the Asserts Manual (AT&T 235-600-500).
Page 5-98, section 5.610.1 (replace)
1. To verify that AMA is recording properly, enter message:
MSG OP:AMA:STATUS;
Response: REPT AMA STATUS FOR STREAM STx
SEGMENT STATUS
----------- ----------
1 xxxxx
2 xxxxx
3 xxxxx
LAST TIME DISK WRITER WROTE TO DISK hh:mm YY/MM
Comment: Save the ROP output for use in the next step.
Note: The percent full (number records) of each of the three SEGMENTS
will demonstrate the loading of AMA records in the SDS. Each time
the SEGMENT gets full, the disk writer writes that particular
SEGMENT to disk. The value of the segment has been written to
disk after the boot.
a. Enter the following message:
MSG OP:AMA:MAPS;
Response: REPT AMA DISK MAPS FOR STREAM ST1
WRITE PARTITION x READ PARTITION x
PARTITION x DISK MAP:
FPO:xx LPO:xx FPS:xx LPS:xx
FSO:xx LSO:xx FSS:xx LSS:xx
FBO:xx LBO:xx FBS:XX LBS:XX
. . . .
. . . .
. . . .
. . . .
2. Re-enter the message:
MSG OP:AMA:STATUS;
Response: REPT AMA STATUS FOR STREAM STx
SEGMENT STATUS
----------- ----------
1 xxxxx
2 xxxxx
3 xxxxx
LAST TIME DISK WRITER WROTE TO DISK hh:mm YY/MM
a. Enter the following message:
MSG OP:AMA:MAPS;
Response: REPT AMA DISK MAPS FOR STREAM ST1
WRITE PARTITION x READ PARTITION x
PARTITION x DISK MAP:
FPO:xx LPO:xx FPS:xx LPS:xx
FSO:xx LSO:xx FSS:xx LSS:xx
FBO:xx LBO:xx FBS:XX LBS:XX
. . . .
. . . .
. . . .
. . . .
3. Note: The amount of time it will take to verify AMA recording depends on
the amount of traffic on the switch. If your office has light
traffic, you should continue with the steps in this manual and
return to Step 2 (above) 10 minutes until you are satisfied that
AMA is recording properly.
Compare the OP:AMA:STATUS output from Step 1 with the
OP:AMA:STATUS output from Step 2.
The amount of AMA recorded depends on the amount of traffic on the
switch.
To verify that AMA is writing to a segment, compare the percent
full (number records) of the segments from Steps 1 and 2. These
should increase with traffic on the switch.
When one segment fills, it should be written to disk and a new
segmentwill begin to fill. To verify that AMA has written to
disk, check the LAST TIME DISK WRITER WROTE TO DISK - this value
should not be 00:00 00/00.
You can also verify the AMA has been written to disk by comparing
the output of the OP:AMA:MAPS commands issued in Steps 1a and 2a.
The second line of the output from the OP:AMA:MAPS gives a number
after WRITE PARTITION. Below this are listed the various
partitions available. Locate that partition corresponding to the
write partition number. Within this report are values for LPO and
LPS. Thse values should increase when AMA is written to disk.
If AMA has successfully written to disk and is writing into a new
segment , AMA is recording properly. If AMA is recording
properly, proceed to the next section.
If AMA is being recorded in one SEGMENT, but has not written to
disk, proceed to the next section but continue to monitor AMA. To
continue the monitoring, reenter the OP:AMA:STATUS message evey 10
minutes until the AMA successfully writes to disk.
If all SEGMENTS still indicate EMPTY, seek techinal assistance.
Caution: If at any time you are unsure that AMA is recorind
properly, do not hesitate to seek technical assistance.
Page 5-140, Table 5-5
The first number under the PTN column should read 0 instead of 1.
Page 5-148, Table 5-12
The first number under the PTN column should read 0 instead of 1.
-------------------------------------------------------------------------------
--=] National Security Anarchists [=--
--=] Volume I, Issue II [=--
--=] Presents [=--
== Traffic Engineering Guidelines ==
== Trunk Port Capacity Provisioning for COs ==
== EG-TFE-91.010.00 ==
EXECUTIVE OVERVIEW:
This guideline provides standards for provisioning trunk capacity (analog
and digital) in the central office switch. This capacity consists of the
forecasted amounts of trunks which terminate on the swithc, sas well as
some quantity, method , to provide for unidentified, unforecasted
requirements. The intent is to ensure the trunk capacity for central
office switches is engineered to cover the core engineering time frame, in
such a manner as to meet the unexpected customer demand and/or deployment
of unforeseen pari gain devices by GTE.
The existing PCM process authorizes engineering for forecasted switch
terminations to accommodate the message trunk forecast, the special
services forecsat, and pair gain host/remote links (future). This
guideline provides instructions for the engineering of unforecasted
miscellaneous switch terminations with COE core job/projects.
GENERAL DISCUSSION:
Competition is pushing GTE to respond to the customer on a shorter time
interval. In order to accomplish this, they must position GTE to allow
for rapid Trunk service provisioning. The availability of central office
Trunk Terminations through controlled engineering for 5-10% unforeseen
demand will ensure their ability to succesfully respond to customer demands
in a timely manner. The time required from customer request to
determination of equipment required, ordering, installing, testing is not
acceptable and is a contributing factor to GTE's loss of customer base.
Proper provisioning of trunk circuits in the right exchanges is essential
to responding to customers' needs.
Agreements are imminent which will provide for planned future pair gain
devices on the PCM by Planning. Existing links for pair gain devices will
be in the POTS/TTE trunk forecast. Therefore, margin for these links are
not provided via this process guideline.
This guideline does not provide margin for the message circuit trunk
forecast trunks. The trunk forecasters will not build margin into the
groups which they manage by the TTE program. In other words, existing or
imminent processes provide for switch terminations to accommodate TTE
forecast and H/R links.
Planning has concurred with their proposal to provide 5-10% margin for
trunk terminations in electronic switches. The decision on the precise
amount of margin to be order should be made by the Traffic Engineer. This
decision will be based on familiarity with the specific wire center and
service demands which have been experienced over the past several years,
along with knowledge of the specific switch configuration. Switches in
remote, slow growth areas would obviously requirrreless margin than
switches in metropolitan, high growth areas. Tandem or class 4/5 switches
may require larger margins due to the unpredictability of IXC demand.
GUIDELINE INSTRUCTION:
The existing PCM process authorizes engineering for forecasted switch
terminations to accommodate the message trunk forecast, the special
services forecast, and pair gain host/remote links (future). This
guideline provides instructions for the engineering of unforecasted
miscellaneous switch terminations with COE core job/projects.
Every core job/project should provision to accommodate unforeseen demand
for central office trunk terminations in addition to the
forecasted/projected requirements of the engineering period. The
unforeseen demand for trunk terminations will typically be engineered at
5% margin for rural offices and 10% margin for metropolitan offices.
Traffic Engineering of more than 10% Trunk Terminations margin will
require Planning review/approval.
Services that comprise unforeseen demand are:
o DID (on COE Forecast as lump sum)
o WATS (when served on trunks)
o Switched HI CAPS/Switched Data (DTI resources) (This is to be
forecasted by Market Forecasting as part of the CAF/SAL forecast.)
o MISC. (analog and/or DTI)
The central office switch common equipment capacity must be engineered to
carry both forecasted and unforeseen demand traffic as if all trunks were
incarry both forecasted and unforeseen demand traffic as if all trunks
were in service by the end of the core period. Twenty-four CCS per trunk
should be used to properly provision the switch's capacity. Application
as two-way split fifty percent incoming and fifty percent outgoing is
recommended unless that traffic engineer knows of local considerations
which warrant a different application.
When the engineer has determined the margin for the unforeseen demand, two
important decisions need to be evaluated: A) exact trunk or T1 quantities,
and B) associated CCS loads.
A. Trunk quantities - The exact number of margin trunks to be added
should be based on the TOGEN calculation of
required trunking and associated frames. Both
analog and digital margin should be provided
(unless a digital switch as been provision with no
analog trunks for DID). Margin trunks should be
calculated to fill frames where possible, and
consideration should also be given to the TCU
layout of the office.
Note: In all cases, when digital technology is the switch type, the
analog trunk frames should be wired so card slots are available
when shortages occur. Digital trunk FIUs can hold two QSIC cards
each, which provides four T1 saaapc lines. Currently they have to
pay right-to-use fees whenever a DTFIU is installed. GTE is
working to implement TRU fees paid as QSIC cards are installed.
Once that is the case there will be value to not installing the
QSIC cards, leaving slots open until they are needed.
Example 1: Metropolitan GTD-5 office requires 200 T1 spans for
forecasted/known trunking requirements.
200 T1 = 25 DTFIU
20 T1 - Recommended margin at 10%
220 T1 = 27.5 DTFIU
Recommendation - Provide 224 T1s to completely fill 28 DTFIUs.
Analyze TCU/FIU layout to assess impact on
TCU requirements. The DTFIU may be eliminated
if it requires an additional TCU.
Note: It is understood this example is representative of a "typical"
metropoloitan office. Engineering judgement, based on specific
site characteristics, may require more than 10% to be budgeted and
installed (with proper approval by Palnning).
Example 2: Rural GTD-5 office requires 30 T1 spans for forecasted/known
trunking requirements.
30 T1 = 3.75 DTFIU
2 T1 - Recommended margin at 5%
32 T1 = 4.0 DTFIU
Recommendation - Analyze TCU/FIU layout. If the fifth DTFIU
can be built into existing TCU, then provide,
if the fifth DTFIU would require another TCU,
do not provide.
B. CCS loads - Once the trunk quantities have been determined, a margin
trunk group should be built into the trunk summary. A CCS load of 24
CCS/trunk should be associated with these margin trunks so that common
equipment wil be calculated to include these trunks (specific impact
will be on TPC processors, MF receivers, and registers in the GTD-5
technology).
If additional TCUs and/or Digital Trunk FIus are required in the GTD5, or
additional Switch Modules are requires in the 5ESS, or more than 10%
margin is required, then Planning must review and provide
authorization/funding.
-------------------------------------------------------------------------------
--=] National Security Anarchists [=--
--=] Volume I, Issue II [=--
--=] Presents [=--
== ATM Research ==
== GTE Project 552 ==
Asynchronous transfer mode (ATM) has been standardized as the target
transfer mode for B-ISDN. It is believed to be a highly flexible
switching and multiplexing technique capable of supporting a wide range
of broadband and narrowband services. Although the conceptual view of
ATM seems attractive, the feasibility of ATM in practice is uncertain for
real-time services such as full-motion video, especially under the
assumption that some degree of statistical multiplexing is desirable
within the ATM network. The objective of this project was to evaluate
the technical feasibility and complexity of ATM for the delivery of four
full-motion video services: television distribution, video-on-demand,
videoconferencing, and videotelephony. The intra-LATA transport of these
video services over and end-to-end ATM network with a standard B-ISDN/ATM
interface was investigated.
The approach was based on a top-down view of the scenario at three
levels: services, network, and switching. At the service level, the four
types of video services and their related end-toend network transport
requirements were characterized. The effects of cell losses and cell
delays on video quality were investigated. At the network level,
alternative service topologies were compared to find the preferred
topology for deployment of each service (see Figure 552-1). The network
management and control issues were examined and traffic control methods
were proposed. At the switch level, the performance and drawbacks of
proposed ATM switch architectures were evaluated for the purpose of
switching full-motion video (see Figure 552-2). Finally, the end-to-end
transport requirements were related to the curretn state of ATM
techonology to draw conclusions about the technical feasibility of each
video service.
Source
________/ \_________
/ \
/ \
/ \
/ \
End Office/Base Unit End Office/Base Unit
/ \ / \
/ . . \ / . . \
/ \ / \
/ \ / \
BERLU BERLU BERLU BERLU
/ \ / \ / \ / \
/ \ / \ / \ / \<- Individualy
/ . . \ / . . \ / . . \ / . . \ Switched
BISDN ------^-^
Loops
Figure 552-1: Preferred service topology for television distribution
services. This topology minimizes the use of network
resources, ensures fast response to channel switching, and
mitigates ATM transport impairments.
____ _______ _________________ _______ _________________ _______ ____
. | 8x8 | . . | 8x8 | . . | 8x8 | .
. | SRM | . . | SRM | . . | SRM | .
__._|_______|_.___ ___._|_______|_.___ ___._|_______|_.__
\ / \ /
\ / \ /
. \ / . \ / .
(8) . X (8) . X (8) .
. / \ . / \ .
/ \ / \
____ _______ _____/ \_____ _______ _____/ \_____ _______ ____
. | 8x8 | . . | 8x8 | . . | 8x8 | .
. | SRM | . . | SRM | . . | SRM | .
__._|_______|_._____________._|_______|_._____________._|_______|_.__
Figure 552-2: A multistage self-routing fabric used in the Fujitsu
FETEX-150 ATM switch. Large ATM switches will be required
in order to offer enhanced video services to a large
customer base.
Television Distribution - Among the four video services studied, TV
distribution services appear to be the most
feasible, but large-scale multicast ATM switches
will be required. A network architecture that
allows switching as close to the customer as
possible is desirable.
Videoconferencing - Network management and control issues are
complex; the design, development, and deployment
of network suitable for videoconferencing will
be a major technical challenge in order to
guarantee quality of service interms of cell
delay/jitter and loss rate.
Videotelephony - For ubiquitous service, the complexity of
network level problems (e.g., traffic control,
network management) will be significant. Large
ATM switches will be required.
Video-on-Demand - For true point-to-point VOD, a robust ATM
backbone with processing capability for
mid-calling signaling will be required. At
present, such a network is not feasible,
although B-ISDN should have this capability. An
area-wide offering is feasible using "local"
video gateways installed at either the access
nodes or in remote units.
Overall, it was concluded that ATM techonology is not yet ready for its
role as a unified means of transport for B-ISDN. Tha main obstacles lie
in the areas of network traffic control and the development of large-scale
switching systems. Without effective solutions to these problems, any
ubiquitous offernign of on-demand, full-motion video services on a public
ATM network is not feasible in the near future.
-------------------------------------------------------------------------------
--=] National Security Anarchists [=--
--=] Volume I, Issue II [=--
--=] Presents [=--
== Teleos: New Access Server Enhancements ==
Multi-Point Token Ring LAN Bridging provides a unique and cost-effective
solution for customers that need to link multiple LAN sites only on an
"as-needed" basis, with the speed (dynamic bandwidth) but without the
incovneience and expense of T1 leased lines. A Token Ring Interface United
(TRIU) provides a 4 Megabit-per-second, IBM Token Ring Network-compliant
interface which supports connections to the AS/400 and other IBM and non-IBM
hosts, front-end processors and communication controllers that support Token
Ring source routing.
The multi-point feature dynamically establishes bridged connections between
up to 32 remote locations. The bridged channel is transparent to higher
layer protocols on the private Token Ring Network. The IAP6000 Access
Server supports 56Kbps, 64 Kbps, 384 Kbps (H0) 1,472 Mbps (H10) and even n x
64 Kbps capability. For instance, a corporate user, for a given
application, can "bundle" 4 x 64 Kbps B channels yielding 256 Kbps of
bandwidth between locations. H0 channels can be concatenated in this
similar fashion. Up to 32 B cahnnel bridge connections may be established
dynamically, on a call-by-call basis, per single TRIU. A total of eight
TRIUs can be supported in a IAP6000 twenty-slot system.
Fractional T1 support using intergrated access allows the user to permanetly
assing channels in 64, 384 or 1,472 Kbps increments for heavy usage
applications. The user now has the option of defining that a certain amount
of bandwidth over a single, intergrated network connection be "fixed" (or
dedicated) for a particular application use. With private line services
over the same Primary Rate Interface access line. For instance, users can
create hybrid networks and use both switched and private line tariffs to
optimize their network costs.
Transparent autoconnect automatically sets up a switched digital call
providing, in effect, virtual dedicated badnwidth on demand for users who
cannot justify the costs of private lines. The IAP6000 Access Server can be
programmed through the system console to dial a specific remote location and
leave the connection active. In this mode, the call is monitored and if for
any reason the connection is dropped, the IAP6000 Access Server
automatically re-establishes the call.
Dynamic event steram reproting enables the IAP6000 Access Server to relay
network information it recieves from the public switched network to an
adjunct information processor (PC, mini, mainframe). The event steram link
is a 9600 Kpbs, asynchronous, RS-232 interface. Information provided over
the D channel, and reported, includes: Calling Party Number Information;
Called Party Number Infomration; Time and Date of the Call, and Call
Type (Voice,Data). Event stream reporting allows the IAP6000 Access Server
to share ISDN D-channel network intelligence with non-ISDN CPE so customized
applications such as call screening, call routing (dealer locator),
automatic call back (for abandoned or busy calls) and secure dial-back
services for comptuer access can be implemented.
-------------------------------------------------------------------------------
--=] National Security Anarchists [=--
--=] Volume I, Issue II [=--
--=] Presents [=--
== SunOS /bin/mail Vulnerability ==
== Sun/Os MicroSystem Security Bulletin =
== Re/Edited Version ==
============================================================================
System Versions : 4.03, 4.1, 4.11
Architectures : Sun3, Sun3x, Sun4, Sun4c, Sun4/490_4.1_PSR_A
Obsoleted by : System V Release 4
Synopsis : /bin/mail can be caused to invoke a root shell if given
the proper arguments.
============================================================================
Synopsis Description:
/bin/mail is the local delivery agent for sendmail. In
some particular instance, /bin/mail parse its argument incorrectly
and therefore, mail are being drop into the bit bucket.
If there are users that has "f" has the second character, you might want
to try the following: (substitute "af" with anyuser with "f" as second
character)
From any machine except mailhost:
/bin/lib/sendmail -t -v <<END
From: anyuser
to: anyuser
Subject: test
Cc: af <-- substitute any username with second character as "f"
test
END
When the mail arrived on mailhost, sendmail process will invoke
/bin/mail with the following argument "/bin/mail -r anyuser -d af
anyuser". Now you are in trouble. The following are different
scenarios for /bin/mail.
[1] /bin/mail -r anyuser -d af <mailmessages fine
[2] /bin/mail -r anyuser -d anyone af ... <mailmessages fine
[3] /bin/mail -r anyuser -d af anyone ... <mailmessages Ah a Bug
In Case 3, /bin/mail thinks that you want to read mail instead of
delivering mail. Therefore, mail messages is lost.
Now this probably won't work on most Internet Sun/Os Unix systems. But ah
this works just dandy on direct dail ups and other networks. So go out
and practice your molestations.
------------------------------------------------------------------------------
National Security Anarchists
"Plagurism is the Basis of Creativity"
## ## ###### ######
### ## ## ## ##
###### ###### ######
## ### ## ## ##
## ## ###### ## ##
-------------------------------------------------------------------------------
National Security Anarchists
"Plagurism is the Basis of Creativity"
All Rights Reserved
Any modifications to this text file is a violation of copyright
- (c) 1991 -
--------------------------------------------------------------------------------
